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RFC 8962 
Establishing the Protocol Police 


Abstract 


One mantra of the IETF is, "We are not the Protocol Police." However, to ensure that protocols are 
implemented and deployed in full compliance with the IETF's standards, it is important to set up 
a body that is responsible for assessing and enforcing correct protocol behavior. 


This document formally establishes the Protocol Police. It defines the body and sets out what 
aspects of IETF protocols they will police. This document acts as a point of reference for 
networking engineers, law enforcement officials, government representatives, and others. It also 
provides advice on how to report issues to the Protocol Police. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is published for informational 
purposes. 


This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor 
has chosen to publish this document at its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by the RFC Editor are not 
candidates for any level of Internet Standard; see Section 2 of RFC 7841. 


Information about the current status of this document, any errata, and how to provide feedback 
on it may be obtained at https://www.rfc-editor.org/info/rfc8962. 


Copyright Notice 


Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights 
reserved. 


This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF 
Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this 
document. Please review these documents carefully, as they describe your rights and restrictions 
with respect to this document. 
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1. Introduction 


IETF participants are often confronted with circumstances where developers or deployers 
choose to not obey the sacrosanct words of an RFC. This can lead to outcomes that are widely 
agreed to be unexpected, unwarranted, or undesirable. 


Some are of the opinion that IETF participants should come to a consensus and declare what 
protocol behavior is unacceptable, and that the maintainers and developers of non-compliant 
protocols should be chastised. Others (especially working group chairs) non-gracefully fall back 
on the undocumented mantra, "We [or the IETF] are not the Protocol Police." Understandably, 
this has led to confusion about who should make judgments about proper interpretation of 
protocol specifications. 


This document formally establishes the Protocol Police, hitherto undocumented at the IETF. It 
defines the body and sets out what aspects of IETF protocols they will police. This document acts 
as a point of reference for networking engineers, law enforcement officials, government 
representatives, and others. It also provides advice on how to report issues to the Protocol Police. 


The Protocol Police, as defined in this document, are responsible for enforcing all IETF standards 
and best practices. 


2. Definitions 


For possibly the first time in IETF history, words like "SHALL" and "MAY" are used in this 
document in their real and enforceable sense. 


3. Composition of the Protocol Police 


The Protocol Police shall be selected by the IETF Nominating Committee (NomCom) as laid out in 
[RFC3797] in a manner similar to that used to select the IAB and IESG [RFC8713]. 


However, the members of the Protocol Police shall not be publicly named. This will enable them 
to operate more effectively and without interference or unwarranted pressure from members of 
the community. The first rule of the Protocol Police is $CIPHERTEXT. 


3.1. Recognizing the Protocol Police 


When more than one person says, "We are not the Protocol Police," at least one of them is not 
telling the truth. 


The Protocol Police love company and are never alone. 


You are not the Protocol Police: we are. We are not the Protocol Police: you are. 
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3.2. Recruitment 


If you are interested in joining the Protocol Police, contact your localhost. Your behavior will be 
monitored, and your implementation will be analyzed for full RFC compliance. If your deeds, 
both now and in the past, are recognized to be true to the scripture, NomCom will of course be 
instructed to induct you to the ranks. But if you have transgressed, any information the 
investigation produces MAY be used against you in future proceedings. 


In making an assessment of your suitability for membership of the Protocol Police, contact may 
be made on your behalf with the Internet Moral Majority [RFC4041]. 


If you have nothing to hide, you have nothing to fear. 


4. Support for the Protocol Police 


Support for the existence and operation of the Protocol Police is essential to the concept of 
"policing by consent." Fortunately, the IETF community and all stakeholders may now consider 
themselves served by this document which, by dint of its existence, warrants adherence. 


5. Punishable Offenses 


5.1. Protocol-Layer Violations 


Some boundaries must not be crossed. There are no acceptable layer violations. Even though 
layers, like borders, are ambiguous abstractions only serving to uphold the legitimacy and 
identity of the institutions that produce them, they shall be observed and defended because the 
Protocol Police exist to defend them. 


5.2. Deliberate Non-Interoperability 


The Protocol Police are sanctioned to gain access to any walled garden that undermines 
interoperability. At the same time, the Protocol Police will defend legacy interoperability options 
in all NTP eras (see Section 6 of [RFC5905]), and will be reachable via the Extensible Messaging 
and Presence Protocol (XMPP) until at least era 2147483649. 


5.3. Disobeying RFCs 


In the beginning was the RFC, and the network was with the RFC, and the RFC was with the 
network. Through the RFC all things were made; without the RFC nothing was made that has 
been made. In the network was life, and that life was the light of all the INTERNET. Thou shalt 
not deviate from the path set out in the RFCs or else thou shall be scattered over the data plane. 


Grover, et al. Informational Page 4 


RFC 8962 The Protocol Police April 2021 


6. Reporting Offenses 


Send all your reports of possible violations and all tips about wrongdoing to /dev/null. The 
Protocol Police are listening and will take care of it. 


7. Punishment 


7.1. Traffic Imprisonment 


The Protocol Police will maintain a list of hosts and clients that have demonstrated their inability 
to comprehend simple commandments contained in RFCs, which all IETF participants know to 
be precise and accessible even to a general audience. 


If this work is standardized, IANA is requested to register the list of addresses (see Section 9). For 
a period specified in an official notification, all other networks SHALL drop all network packets 
originating from or intended for such addresses. This will result in effective and forced 
confinement of criminal networks. 


Using powerful machine-learning mechanisms for threat analysis, the Protocol Police will 
identify networks that are likely to fail to comply with this requirement. This process is known as 
Heuristic Internet Policing (HIP). Networks identified in this way will be disciplined by the 
Protocol Police with TCP RSTs. Let it be known: the Protocol Police always shoot from the HIP. 


8. Morality Considerations 


This section contains morality considerations consistent with the demands of [RFC4041]. 


We reject: kings, presidents and voting. 
We believe in: rough consensus and running code. 
We only bow down to: the Protocol Police. 


— My friend Dave 


Woop-woop! This is the Protocol Police! 
Woop-woop! That's the packet of the beast! 


— KRS-ZERO (after spotting an evil bit [RFC3514]) 


8.1. Oversight 


All police forces must be accountable and subject to oversight. The Protocol Police take full 
responsibility for oversight of their actions and promise to overlook all activities. 
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9. IANA Considerations 


If this work is standardized, IANA shall set up a registry for criminal networks and addresses. If 
the IANA does not comply with these orders, the Protocol Police shall go and cry to ICANN before 
becoming lost in its bureaucracy. 


10. Security Considerations 


Before the Protocol Police, there was no security. The Police have arrived. All your networks are 
belong to us. 


11. Privacy Considerations 


None. 


12. Human Rights Considerations 


There are none for you to worry about. The Police will see to it. 


13. Conclusion 


Case closed. 
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